Has the other PR really been abandoned, or is the author merely focused on other tasks or even away from work? The latter would not be surprising considering that we are approaching the end of the year.

This patch squashes all changes from #705 into one, along with new changes. I suppose that this was the easiest way to rebase, but it causes the lost of context because some individual commits offered context that are missing from the squashed commit.

Out of all, I think that it would make most sense to include the context of 59d7b4b addresses #769 . E.g. by including the issue reference in the commit message ("Fixes xxx") and a code comment pointing to the discussion.
I have not reviewed the updated patch yet, but note that in the previous PR there was still an active discussion on this topic at #705 (comment)

I'd really like if the test was moved over to python.

I've been trying to contact authors since late October but did not received any reply. I would happily keep the original PR but I want to move this forward. Especially now when the Firefox part landed.

The squash was suggested, so I did it. I'll check the 59d7b4b
I plan to do some testing because I'm getting various app_ids as I've mentioned in #705 (comment)

In latest update I've fixed the xdp_app_info_get_gappinfo call and stopped to use g_desktop_app_info_new.

I plan to do some testing because I'm getting various app_ids as I've mentioned in #705 (comment)

That's the usual issue we have with host apps. The application id comes from cgroups, which is set depending on the way you start the app, e.g. you start it from a terminal app it might get app id of the terminal app. Or you start it with Alt + F2 in GNOME and the app id will be just firefox. Flatpak apps are reliable in this case.

See #1512 what we did for the camera portal, where this was causing issues.

Regarding the appid mismatch that unfortunately still happens: I'd much rather see us adding #1521 than special casing every portal that firefox actually depends on.

I'd really like if the test was moved over to python.

Looking at the python vs C tests, there seems to be missing permission store service in Python. I'm not sufficiently familiar with the code to implement it for python tests or is it done somewhere already?

The permission store is supposed to get started (https://github.com/flatpak/xdg-desktop-portal/blob/1c902cc77e53b422d49988bab58b6cca0ed9b112/tests/conftest.py#L458C5-L458C25) when the test case uses either the xdg_permission_store or the more general portals fixtures.

The proposal (by @swick) suggests replacing xdg-desktop-portal with a separate service, org.freedesktop.native_messaging, for native messaging API support. This would make the feature exclusive to browsers using the --talk-name=org.freedesktop.native_messaging permission. On the other hand it removes the user access dialog provided by xdg-desktop-portal.

The service API remains unchanged, but as noted by @swick, this approach does not address potential sandbox escapes but it will be exclusive to those who want to use the org.freedesktop.native_messaging.

@Rob--W please share your thoughts from the Firefox point of view and all the work that has been done on the Firefox side.

Could you elaborate on the changes that you're considering? What are the current values and the proposed values?

It sounds like the proposal may effectively introduce a backwards-incompatible change, requiring changes to https://searchfox.org/mozilla-central/rev/7d1b5c88343879056168aa710a9ee743392604c0/toolkit/components/extensions/NativeMessagingPortal.cpp#110-112, and maybe other places too.

The feature in Firefox is currently disabled by default to offer room for such breaking changes if really needed. I would imagine Canonical to either apply distro-specific patches to Firefox, or update the portal to transition to the new state. But I cannot speak on behalf of them, so once you've clarified the exact changes that you're considering, I'll ping them.

Could you elaborate on the changes that you're considering? What are the current values and the proposed values?

@swick I'm not sure how the separate service will support creating and maintaining sessions currently implemented by xdp. Could you help?